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Introduct* on 



This document is intended as a guide to those who need 
to understand and/or write device drivers for tne XXDP* 
Vc system. Section 1.0 below describes the bas c 
differences between VI and V2 drivers. Sect 'on 2.0 
outincs the phvsical layout of the driver. Section 3.0 
describes the runctlons performed by drivers while 
sect 'on 4.0 offers advice to those intending to 
maintain or write a device driver themselves. 

Throughout this document there are many references to 
the mnemonics of the file structure. These are listed 
in the glossary for convenience. A desriptlon of the 
file structure may be found in the file structure 
document listed in the b I biography. 



Differences between VI ano V2 Drivers 

One major purpose of XXOP* V2 is to simplify the 
maintenance of XXDP components. A facet of this 
s'mpi 'f Icatlon is to make drivers as uniform as possible. 
To this end: 

a) Functionality which seemed more file-oriented then 
device -oriented (e.9. file search) was migrated to 
a front -end. which is now incorpo'if'^ed in a 
version of UPD2 and other utilities. 

by Read-only and Read-write functionality was 
recombined so that a single driver may be used 
both by the Monitor and by utilities. 

c) Some functional aspects of individual drivers were 
changed, ^or instance, most drivers will now 
Svipport two units (previously a different copy 
was needed for each unit). 

d) '^he layout of all drivers was made as uniform as 
possible. 

e) D"si< organization has been made uniform (MFO 

.^ar'ety 01* has been retired). 

f) Some functional aspects of the Utilities were 
c*^9nged. UP02 will no longer permit an Image 
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Conpat ibi 1 i ty 

Cotnpat ibi 1 i ty b«tMe«n V2 and VI has been maintained, 
witH tHc following exceptions: 

1) The VI OL and OH disk layout did not allow 

for a 32k Monitor. If the V2 Monitor s 'nstalled 
on • VI Mcdiuo). the first file (or two) after the 
•on i tor area will be corrupted. 

2) The MFD variety #1 has been retired for the DB. 
OD. OU and OY drivers. V2 drivers may be used to 
read or write VI media. VI drivers may be used 
to read V2 media, but not to write. (Except in 

the case: VI MS drivers will not read V2 MS tapes.) 

3) V2 media will have the octal constant 1002 at 
octal displacement 14 (the old MF02 pointer) in 
the MFD. VI media will have some other value. 
The MFO is not currently read by most drivers, so 
this fact is not used. 

4) The VI MM and MS tape layouts each had two Monitors 
at the tape beginning, selected according to what 
device was being booted. The V2 layouts have only 
one Monitor as the first file on the tape. 



Device Driver Layout 

This section describes the lexical structure of XXDP 
Version 2 device drivers. The requisite conponents are 
outlined below with descriptions as to their functions 
and usage. Definitions of terms relating to file 
structure may be found in ( AC-S666A-M0) CHQFSAO XXDP* 
File Structure Document, 

Driver Revision History 

This section contains a brief history of attributed 
source code revisions, as Is standard for DEC software. 
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2.2 Syabolic Equates 

2.2.1 Device -Independent Equates 

This section contains definitions for data structure 
offsets and other equates which are more or less common 
to all drivers. 

1) OIRBLK Offsets 

These equates describe the OIRBLK structure in 
the driver, discussed below. The OIRBLK contains a 
description of the (disk) layout. 

2) DOB Equates 

These equates describe the 'Oevice Oescriptor 
Block' (006). a data structure which is found in 
the utilities, and a subset of which is found in 
the Monitor. The DOB provides the driver's data 
interface. The driver's Parameter Table will 
overlay or be copied to the DOB. 

3) Device Comnand Codes 

These equates are the command codes, issued by a 
utility or the monitor, to which the driver 
responds. Some command codes, e.9. WRITE), are 
used by all drivers. Others may be specific to 
device type (e.o. bad-block ino) or to the device 
itself (e.g.RFSTFN- reformat RX02 single density). 

4) Parameter Table Equates 

Uhen the dr i ver i s loadedby a ut i 1 i ty , i ts 
parameter table is copied into the DOB. These 
equates are thus actually DOB offsets. 

5) Device Returned Status Byte 

These equates describe the meaning of the bits in 
the above-mentioned OVSB byte. They concern disk 
density and tape drive status. 

2.2.2 Device -Dependent Equates 

These are equates particular to the device and driver code. 

1) Program Equates 

These equates are typically mnemonics (e.g. LF 
or CR) used for convenience In the code. 

i') Device Equates 

''hcsc equates describe internal device codes, 
status words, commands, and packet formats. 
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D^ta St'-uctures 



2.3.1 Device Parameter Table 

This data structure begins the driver's actual code. 
Uh«n the the Monitor is CREATED by the UPDATE utilty 
the driver is appended to the end of the monitor and 
this table overlays the Monitor's DDB. Uhen the driver 
is loaded bv a utility, this table is copied into the 
utility's 006. addresses being relocated appropr ' ately . 
From this time on, the table is referenced largely 
through this OOB copy: the driver s copy is used only by 
the driver's INIT routine in anticipation of the next 
load. All driver routines assume that R5 points to the 
command register entry in the POB. 

(Note: in order to save space, some of the parameters 
have been given INITIAL values and functions which are 
not related to their functions during execution.) 

A Parameter Table Example Is: 



PAR AM: 


DISPAT 






.UORO 


"DZ 




.BYTE 


BBSUP$ 




• BYTE 


44 




.UORO 


BCOOE 


UNIT: 


.BYTE 


0 


ERRB: 


.BYTE 


0 


CMDREG: 


174400 




UCOUNT: 


0 




BUSAOR: 


0 




BLOCK: 


0 




COMO: 


0 




DIRPTR: 


OIRBLK 




ASNAME: 


0 




PARENO: 







DISPATCH ROUTINE 
DRIVER NAME 
DEVICE CODE 

RETURNED STATUS (INITIAL DEVICE 

TYPE) 

BOOT CODE OFFSET 



(INITIAL REV 0) 
(INITIAL PATCH 0) 



UNIT 0 

ERROR STATUS 
COMMAND REGISTER ADOR 
UORO COIMT 
BUS ADDRESS 
BLOCK NUMBER 
COMMAND 

POINTS TO 1ST OIR BLOCK. 
FOR MONITOR COMPATIBILITY 



1) Dispatch Routine Address 

Th's entry is the address of the dispatch 
routine, which determines which driver routines 
to Involve. All driver services are provided 
through this entry. 

2) Dr'ver Name 

"^h's entry is the device's two byte mnemonic name. 
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3) Device Code 

This static byte is used to indicate that the 
device has special features of interest to 
utilities. Current flags are: 

BBSUPt • Device provides bad block support. 

NQDIR* - Not a directory device 

TAPED$ - Tape device 

REFDN$ - Supports single/double density reformat. 

MULUNJ Driver supports 2 units/driver 

NOREN$ - Device does not support file rename. 

FLOADt - Device may have floating address. 

4} Device Status 

This byte is returned by some drivers in response 
to inquiries concerning disk density or tape 
status. Current flags are: 

DDDEN$ - Disk is double density 

BOTTP$ - T^ is at physical bot 

TnKTP$ - Tape is at tape mark 

EOTTP$ - Tape is at ohysical eot 

(The INITIAL value of tMs Lyte communicates a device 
type code to the tlortitcr .mmcdiately after the 
driver is loaded. See appendix 0.) 

5) Boot Code Offset 

''his entry contains the displacement to the boot 
code, i.e. to the end of driver code. This is 
used by the Monitor and does not further concern 
the driver itself. 

6) UNIT 

This byte entry communicates the device unit C 
to the driver. This is commonly addressed as 

X0N(R5). 

(The INITIAL value of this byte communicates the 
version number of the driver.) 

7) ERRB 

This byte entry is used by the driver to 
communicate errors and (sometimes) attention 
conditions. It is tested immediately prior to 
driver exit (as XER(R5)). 

(The INITIAL value of this byte communicates the 
patch number of this driver.; 

8) CMDREG 

Th's is the address of the primary device command 
register. It is the focus of the DD6 and is used 
by the dr'ver to access all device registers. 
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9) UCOUNT. BUSADR. BLOCK 

These entries are used to communicate to the 
driver, the count, address, and block number of 
a transfer command. 

10) COMD 

This entry contains the coded command to be 
performed by the driver. This code is 
interpreted in the driver's dispatch routine. 

11) DIRPTR 

This entry points to the driver data structure 
OIRBLK, a table which describes the physical 
layout of a disk. This pointer is the only 
exception to the rule that local entries m this 
table (as opposed to their copies in the DOB) 
are not used. The driver's INIT routine may toggle 
this pointer for some "two-unit " drivers to point to 
an alternate OIRBLK structure to be active on the 
next load. This feature permits one driver to be used 
with two units with differing densities, etc. 



2.3.2 OIRBLK 

This data structure communicates particulars of the 
device's physical layout. Its first several entries 
mirror the structure of a variety 92 MFD, which Is now 
used for non-bad-blocking devices as well. Note that 
for non-bad-block ing devices, the data contained in 
OIRBLK is constant and the MFO need never be actually 
read. For some drivers which support two units, OIRdLK 
will be replicated, and OIRPTR will be toggled back and 
forth by the driver's INIT routine. 



2.3.3 Local data 

This section contains data structures used internally by 
the driver to store state information, construct packets, 
etc. Some unit -dependent local data may be appended to 
OIRBLK to take advantage of OIRBLK switching for two-unit 
drivers. 



2.3.4 Error Messages 

Th's section contains the error messages printed by the 
driver. The utilities may append information to such 
messages, e.g. if the driver prints "RO ERR", the utility 
will note the error through the error byte XER(R5), and 
may append, for example, "IN INPUT DIRECTORY". 
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^.4 Executable Code 

2.4.1 DISPATCH Routine 

The dispatch routine receives control from the utilty or 
monitor, examines the command code in the ODB, and gives 
control to subordinate routines. Dispatch may. in 
addition, perform code sequences common to its sub- 
ordinates or indeed perfo^^m some simple commands. Just 
prior to exit, the dispatch routine tests the error byte 
XER(R5) so that the calling utility may make an immediate 
branch on error. At present, some dispatches are "test 
and call" and some table driven. In drivers with more 
than 4 such tests, a table driven approach may save 
space . 

2.4.2 INIT Routine 

The in it routine receives control from dispatch. Its 
primary function is to perform any physical initial- 
ization and to set local 0IR6LK variables to reflect unit 
characteristics. It is assumed to have been called 
immediately after the driver is loaded. In it may also 
perform auxiliary functions, such as determining device 
density. 

2.4.3 DRIVER Routine 

The driver routine receives control from dispatch. It 
commonly handles I/O transfers. In many cases, the code 
in this routine is largely unchanged from that in VI. 

2.4.4 Auxiliary Routines 



These routines are called by DISPATCH. INIT and 3RIVER. 
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3.0 Device Drivers Funct ons 

3.1 All Drivers 

There is a minimal set of funct ons Hhich all drivers are 
expected to perform: 

INIT$ 

This function is invoked once per device-unit, 
either after the Monitor has been loaded or immediately 
after a utility 'loads' a driver. Note that if a 
utility finds the requested driver to be already present, 
it n!11 not load a fresh copy. Before INIT$ is invoked, 
parameter table information has been copied (or in the 
case of the Monitor, overlayed) on to the DDB: in 
particular DIRPTR has been converted from relative to 
absolute address (but only on a fresh load). 

Tasks to be performed at this time include device 
initialization (e.9. DU performs an initialization 
sequence at this time when the value of a local variable 
signifies that it is a fresh 'load') and intialization 
of local variables. Disk drivers which support bbd- 
blockinq use this occasion to read the disk MFD and 
set DIRBLK variables accordingly. Some drivers which 
support two units with differing characteristics (e.g. 
density) will toggle the (local) pointer DIRPTR at this 
time so that on the next 'load', a different DIRBLK will 
be used. 

You will see that, in those drivers which have a GTMFDl 
routine to read the MFD. a DIRBLK flaa XXMFID Is checked 
before any disk read Is done. This flag Is raised by 
the driver loading routine In the utility when a ZERO 
directive Is In progress - In order to avoid reading 

d'unk from a disk which Is about to be cleared. The 
IR6LK structure Is updated by the utility during the 
ZERO execution. 

RES*FN 



This function is Invoked by the Monitor to read some 
blocks from the Monitor Image, presumably after possible 
corrupt Ion. 

At this time the code relocates the requested block 
number by the starting Monitor block number. The code 
may assume that this entry In DIRBLK is either a 
constant or has been updated during INIT$ processing. 
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READ! 



This ft»>ction is used by all drivers except LP:. 
It is invoked by the Monitor or the utility to read 
a block or series of blocks from the device. The word 
count, buffer address and starting block number (for 
direct access devices) are found in the ODB. 

It is the driver's function to convert the Mord count 
and block numbers if necessary, to initiate the transfer, 
and to wait until successful completion. If an error is 
detected, the driver may try to effect recovery (e.g. 
several disk drivers now have ECC correction routines). 
If recovery is impossible, failure is communicated by 
setting the XER byte in the 006 to a non-zero value. 

URITEt 



This function is used by all drivers. All comments 
concerning REAO$ above are applicable here. 
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3.2 Disk Drivers 

Disk devices are all directory structured. This is 
signalled to the utility by having a positive first entry 
in the DIRBLK table. A disk driver may have functions in 
addition to those above: 

REDIFN 



This function requests the read of an absolute 
cylinder/track/sector from a bad-blocking device. It 
is invoked by the ZERO command execution in UPD2. 
UPD2 places the cylinder, track and sector addresses 
of the bad-block file (determined from DIRBLK) into 
the DDB and issues the call. 

CMPJFN 



The format of the bad-block file is a list of 
cylinder/track/sectors. The ZERO routine in UPD2 issues 
a CMPJFN to convert these to block numbers, which it 
uses to set the appropriate bit-maps. 

DENJFN 

The ZERO routine in UP02 needs to knoM the disk density 
to find the correct location of the bad-block file. 

The driver returns a flag in the DOB status byte OVSB. 

0 = single density 

1 = double density 

RFS*FN.RFD«FN 



The DY driver performs hardware re-formatting of a disk 
to s'ngle or oouble density (as communicated to UPD2 
through the ZERO command). 
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Tape Drivers 

Drivers for tape devices (comnunicated via the device 
code bvte in tne DD6 and by a negative first word in 
DIR6LK; provde a variety of functions not needed for 
disk devices. Tapes are not directory devices - every 
file is preceded by a header which contains the file name. 
The logical end of tape is a double EOF. In addition to 
those f unct ' ons 1 i sted as coiMnon to aJ 1 dr ; vers above : 

PRE* TP 



This function is invoked to set up the tape controller 
for subsequent commands. 

PEU)TP 



'This function is called to rewind the tape. 
SPR»TP 



This funct'on 's called to backspace the tape. 
UHDtTP 



Th's function is called to write a 7 word header. 
RHO»TP 



"his function is called to read a header. 

SEF$TP 



This function is invoked to skip to an EOF, i.e. to 
skip the rcma'nder of a file. 

UEFfTP 



This function is called to Mritc an EOF on tape. 
SET$TP 



This function is called to skip to the logical end 
of tape. '.c. after all files. 

STA$TP 



This function Is Invoked to return the tape status 
(at BOT.TMK, physical EOT) through the device status 
byte In the DDb. The tMO existing tape drivers. MM 
and MS approach this differently. MM backspaces the 
tape and then forward spaces. If 60T was detected 
during the backspace, this Is returned as status. 
Otherwise the status detected dur'ng the forward space 
's returned. The MS driver interrogates the controller 
In real t'me. 
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•i.C Ur't"ng 8 Driver 

The best approach to writing a driver is to model it on 
e\"stng ones. The drivers that presently exsist provide 
a Hide variety from which to choose, and are br'efly 
characterized along several dimensions at the end of this 
section. Some points to note: 

1) Much of the driver preamble is dev ice- independent and 
may be copied wholesale. Look at the preamble of UP02 
to determine the symbolic command codes etc. with 
which the utilities and drivers commun'cate. 

2) The dev Ice -dependent components of the preamble 
follow Informal conventions, e.g. control reg'ster 
names are often similar from device to device. You 
may b« able to copy this, with minor changes, from 
some driver with a similar communications structure. 

3) The parameter tables of all drivers are Quite similar. 

4} The OIRBLK specifies the physical layout of a disk 
device. Be careful how you lay out a disk structure - 
do not lock yourself into a structure which cannot be 
easily expanded to meet similar but laroer devices, 
^or example, you might want to put the Monitor image 
towards the beginning of the disk, before the UFD and 
Bitmaps, so that the bootstrap routine doesn't have 
to contend with these areas as they change from device 
to device. 

An example of a good structure might be: 



Block Purpose 



0 Secondary bootstrap 

1 MFOl 

3 Start of Monitor image 

35. First UFD block 

35. • N First bit map 

35. • N • M c of blocks to preal locate 



Remember that, even though they are linked. LfTO and 
b't map space are allocated contiguously by UPD2 at 
dev'ce ZERQIng. It is. In fact, this contiguity which 
results in the possibility that the actual parameters 
may differ among bad-block mg devices. 

5 J The DOB error byte ERR(R5) Is used to communicate 
failure. The driver must test this byte immediately 
before ex'ting. Note that the polarity of this device 
's jsed to commun'cate different flavors of fa'lure: 
e.g. •! often means 'dcv*cc full'. 
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61 If you plan to have your driver support 2 disparate 
devices at the same time (e.g. bad-block mg devices 
are disparate because the actual location of some 
things may change. There is a limit to this: the 
boot routine may assume a constant location for the 
Monitor image), you ma^ want to toggle between two 
DIRBLK's. Be careful, m this case, to remember that 
the parameter table actually overlays the DDB when 
the driver is linked with the Monitor; toggle before 
any changes are made to DIRBLK. 

''') The DRIVER routine in many drivers disambiguates some 
of the commands. This is due to historical reasons 
and commonality of some code. 

5) Driver code must be location- independent. In part- 
icular, this means that if addresses of local data 
are manipulated, they must be calculated dynamically 
rather than by the linker. E.g. 

MOV «TABLE.RO : will not get the address of 

i TABLE 

but 

MOV PC.RO 

ADD «TABLE-..RO : will work 



9) All code must be processor independent . 

10) The disk layout (reflected in DIRBLK) of some bad- 
blocking devices depends on the medium density. Uhen 
a driver is 'loaded' as a result of a ZERO command, 
the MFD refreshed Indicator in the DIRBLK is set by 
UPD2 prior to Invoking the INIT function. This is 
tested In the driver's GTMFDl routine to bypass en 
MFD read (the MFD may be Junk). The UPD2 ZERO 
command will issue a DENtFN to the driver to 
determine the disk density, and will compute the 
bad block file and bad-block dependent attributes 
(first UFD, bitmap, and Monitor) accordingly. It will 
not. however, set up the remaining density -dependent 
DIRBLK entries: this should be done by the driver's 
INIT code with consideration that the MFD might not 
be read. 

11) The MFD for all devices is written by UP02 during a 
ZERO command, and. for bad-blocking devices, must be 
referenced (because it contains variable information) 
by the driver during an INiT function to update the 
DiRBLK. The variables to be updated are starting UFQ. 
Mon'tor, and bitmap block numbers. Except for this 
reference, the driver need not concern itself with 
the HFD variety or structure. 
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D«v'c« Driver Characteristics 



DB - RJP04.5.6 



Type 

B»d-block!ng 
Error -recovery 
CoMRuni cat ions 
DIRBLK 

Tmo or» its/driver 
Oispetch 

OD - TU58 

Type 

Bed-blocking 

Error-recovery 
CoMHjni cat ions 
DIRBLK 

Tmo units/driver 
OispatcH 

Dl • RL01.02 
Type 

Bad-blocking 
Error - recovery 
CoMRuni cat ions 
DIRBLK 

Two units/driver 
Dispatch 

DM - RK06.7 

Type 

Bad-blocking 
Error -recovery 
CoMMuni cat ions 
DIRBlK 

Tmo units/driver 
0 1 spatch 

DR - RMO2.03 

Type 

Bad-blocking 
Error - recovery 
Co<Miuni cat ions 
DIRBLK 

Two units/dr'^er 
D i spatch 



Disk 
No 

ECC correct ion, retry 

Device registers 

Constant 

Yes 

Table 



Disk (directory structured tape) 
No 

Retry 

Packet 

Constant 

Yes 

Table 



Disk 

Yes 

Retry 

Device Registers 

Variable according to bad-blocking 

and density. 

Yes 

Table 



Disk 
Yes 

ECC correct Ion, retry 
Device Registers 

Variable according to bad -blocking 

Yes 

Table 



Disk 
^es 

ECC correct ion, retry 
Device Registers 

Variable according to bad-blocking 

res 

Table 
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OU UOA 50.ro/RX 



Type 

Bad-block ing 
Error -recovery 
Co«iM>urv icBt ions 
DIRBLK 

Tmo units/drtver 
0 1 spatcH 



O'sk 

Transparent to driver 
MSCP 

Variable according to drive capacity 
Yes 

Test and call 



01 - RX02.01 (does not boot RXOl) 



Type 

Bad-block ing 
Error -recovery 
CoMMjni cat ions 
OIRBLK 



Two un"ts/driver - Yes 
Dispatch - Table 



Oisk 
No 

Retry 

Device Registers 
- Variable according to RXOl/02 



LP - Line printer 

Bad-block ing 
Error - recovery 
Co«MHjni cat ions 
OIRBLK 

Tmo units/driver 
0 1 spatcH 

m - TM02 

Type 

Bad-block ing 
Error -recovery 
CoMMuni cat ions 
DIRBLK 

Tmo units/driver 
0 i spatch 

MS TS04/TS11 



Bad-block ing 
Error recovery 
Co«M'jn i c at ' ons 
OIRBLK 

Tmo units/dr'ver 
0 ' spatch 



- Line printer 

- Huh? 

I 

Device reoisters 

- Constant 0 

- No 

- Test and call 



- Tape 

- Retry 

- Device registers 

- Constant -1 

- Yes 

• Table 



Tape 

- Retry 
Packet 

- Constant -i 
I'es 

Table 



G2 

Page 19 



GLOSSARY 

IR6 - Interrccord gap. The gap that is written 
bctMecn records on magtape. 

MFD - Master File Directory 

RAO-50 - RAOIX-50. A method of encoding 3 ASCII 
characters into one 16 bit word. 

UFO - User F;ie Directory. 

UIC - User Identification code. 
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Appcd ! c i es 



Appendix A Driver and Boot Example 

The following is an example of a working driver (DO:), ed ted 
sligHtlly to explicate structure. 



.NLIST CNO 

.TI'LE RJP04.5.6 - XXDP* V2 DRIVER 
.SBTTL DRIVER REVISION HISTORY 



.' REV DATE CHANGE 



• 
• 


1 


.0 


31 


-JUL 


-78 


INITIAL ISSUE 


• 


1 


.1 


17 


-NOV 


-78 


MAKE COMPATABLE UITH BIG DRVCOM 


• 


2 


.0 


11 


-AUG- 


-80 


XXDP* VI. 1 COMPATIBLE 


• 












REMOVED READ-ONLY CODE 


• 












ADDED XER(R5) AS RESULT STATUS 


* 












ADDED INIT ROUTINE 


a 












REMOVED CLEAR MAPS ROUTINE 


f 
• 






21 


■FEB- 


84 


CHANGE FOR V2. INCLUDING ECC CORRECT 


a 






06- 


-MAR- 


84 


TUO UNITS/DRIVER - GOT RID OF GTMFDl 


• 






18 


flAR- 


84 


TABLE DRIVEN DISPATCH 


• 






25 


-APR- 


84 


INITIALIZE RETURNED STATUS BYTE 



.PAGE 

•NLIST ME.CND 

.NLIST MC 

.LIST MEB 

.SBTTL DEVICE -INDEPENDENT EQUATES 

I'dIRBLK OFFSETS 



XOIR 


=0 


ilST DIR BLOCK. 


XOIRN 


=2 


i# OF DIR BLOCKS. 


XMP 


=4 


,1MAP BLOCK #. 


XMPN 


=6 


ff OF MAP BLOCKS. 


XMFDl 


=10 


[MFDl BLOCK 9. 


XVERS 


=12 


XXDP VERSION 9 (1002 = VERSION 2) 


XMXBK" 


= 14 


MAX BLOCKS UORD. 


RSBK 


= 16 


* OF BLOCKS TO RESERVE. 


ITLVE 


=20 
=22 


INTERLEAVE FACTOR. 


BOTBK 


BOOT BLOCK. 


MNBK 


=24 


MONITOR CORE IMAGE BLOCK. 


XMFID 


-26 


MFD REFRESHED INDICATOR. 



12 



DEVICE DESCRIPTER BLOCK (DOB) EQUATES 

DOB OFFSETS FOR R/U DRIVER 

DOB OFFSETS FOR MONITOR ARE A SUBSET 



XREU 


» -50 


: INDEX TO INHIBIT REUIND INDCATQR 


XUCTR 


* -46 


: INDEX TO URITE COUNTER 


XUILO 


X .44 


: INDEX TO WILDCARD INDICATOR 


XFLCNT 


« -42 


: INDEX TO FILE COUNT 


XSVMAP 


« -40 




XSVBLK 


« -36 




XSVOAT 


* -34 




XBKLGT 


« -32 




XLSTBK 


. -30 




XBUF 


. -26 




XSVCNT 


* -24 




XSVNAM 


« -22 




XSVEXT 


« -16 




XISTBK 


* -14 




xsv 


= -12 


INDEX TO SERVICE ROUTINE (DRIVER) 


XON 


= -2 


DRIVE NUMBER INDEX 


XER 


= 1 


RESULT STATUS 


XCM 


= 0 


INDEX TO COMMAND REGISTER 


XUC 


= 2 


INDEX TO WORD COUNT 


XBA 


= 4 


INDEX TO BUS ADDRESS 


XU 1 


- 6 


INDEX TO BLOCK NUMBER OR TAPE SKIP 9 


XCO 


= 10 


INDEX TO COMMAND 




= 12 i 


INDEX TO 1ST OIR BLOCK POINTER 


XXNAM 


= 14 i 


INDEX TO ASCII NAME IN DOB 


XBC 


= 16 ! 


INDEX TO REQUESTED BLOCK COUNT 


XNB 


= 20 : 


INDEX TO LAST BLOCK 0 ALLOCATED 


XCKSUM 


= 22 : 


CHECKSUM CALCULATION IN SEARCH 


SVC 


= XSV {ALTERNATE NAME 


COMMAND 


COOES 





INITJ 


» 0 


: INITIALIZE DEVICE AND BRING ON LINE 


REAOi 


- 1 


: READ 


URITE J 


= 2 


: URITE 


RESJFN 


= 3 


: RESTORE FUNCTION FOR MONITOR 


01 S 


= SVC 


DISPATCH TABLE 



CODE BYTE 



MULUN$ = 100 ; DRIVER PERMITS MULTIPLE DEVICES 



PAGE 

SBT7L DEVICE -DEPENDENT EQUATES 



J2 



S£Q 0022 



RJP04 FUNCTION EQUATES 



RPUC 

RPBA 

RPOA 

RPCS2 

RPERl 

RPOF 

RPOC 

RPECl 

R''EC2 



2 
4 

6 

10 
14 
32 
34 
44 
46 



RJREAO = n 
RJURITE = 61 
DONE - 200 
ERROR ' 100000 



RJP04 WORD COUNT REGISTER 

RJP04 BUS ADDRESS REGISTER 

RJP04 DESIRED SECTOR/TRACK REGISTER 

RJP04 CONTROL STATUS REGISTER 2 

RJP04 ERROR REGISTER 1 

RJP04 OFFSETT REGISTER 

RJP04 DESIRED CYLINDER REGISTER 

RJP04 ECC POSITION 

RJP04 ECC PATTERN 

RJP04 RITAD COMMAND 
RJP04 URITE COMMAND 



I<2 



.PAGE 

.SBTTL XXOP DEVICE DRIVER PARAMETER TABLE 



DEVICE -DRIVER PARAMETERS 
THESE PARAMETERS ARE JSED IN COMMUNICATION WITH THE UTIlITY 
PROGRAM 



PARAM: DISPAT 
.UORD 
• BYTE 
.BYTE 
.UORO 

UNIT: .BYTE 

ERRS: .BYTE 

CMOREG: 176700 

UCOUNT: 0 

BUSAOR: 0 

BLOCK: 0 

COMO: 0 

DIRPTR: DIRBLK 

ASNAM: 0 
PARENO: 



"DB 

MULUNJ 
11 

BCODE 

'A 
'1 



DISPATCH ROUTINE 
DRIVER NAME 
DEVICE CODE 

RETURNED DEVICE STATUS (INT DEVICE TYPE) 
BOOT CODE OFFSET 



UNIT 0 

ERROR STATUS 
COMMAND REGISTER AOOR 
UORO COUNT 
BUS ADDRESS 
BLOCK NUMBER 
COMMAND 

POINTS TO 1ST OIR BLOCK. 
FOR MONITOR COMPATIBILITY 



(INTIAL REV # A ) 
(INTIAL PATCH « 1) 



.PAGE 

.SB77L DIRBLK TABLE 



PARAMETERS USED TO DEFINE DISK LAYOUT 



DIRBLK: 3 

170. 
173. 
50. 
1 

1002 

48000. 

255. 

1 

0 

MONBLK: 223. 
0 



1ST UFD BLOCK ADOR 

NUMBER OF UFD BLOCKS 

1ST BIT MAP BLOCK ADOR 

NUMBER OF MAP BLOCKS 

MFDl BLOCK ADOR 

VERSION 2 FLAG (NOT UPDATED) 

MAX NUMBER OF BLOCKS ON DEVICE 

# OF BLOCKS TO PREALLOCATE AT ZERO 

INTERLEAVE FACTOR 

BOOT BLOCK « 

MONITOR CORE IMAGE BLOCK # 

MFD REFRESHED FLAG. 0«N0. NON 0-YES 



•SBTTL LOCAL DATA 

\ LOCAL DATA AND ERROR MESSAGES 



ECCPAT: .WORD 0.0 
.SBTTL ERROR MESSAGES 



MUTERR 
MRDERR 
ILLERR 



{STORAGE FOR EGG CORRECTION 



.ASCIZ <40><40>' ? UT ERR' 

-ASCIZ <40><40>' ? RO ERR' 

.ASCIZ <40><40>'? ILLEGAL CMNO ERR' 

.EVEN 



M2 



.PAGE 



SBTTL MAIN DISPATCH ROUTINE 

DISPATCH ROUTIf€ FOR DRIVER 

THIS ROUTINE RECEIVES CONTROL FROM A UTILITY 
OR DRVCOM. IT EXAMINES THE COMMAND CODE IN 
XCOCRS) IN THE DOB. AND CALLS THE APPROPRIATE 
LOCAL FUNCTION. 



INPUT: 
OUTPUT : 



XC0(R5) 



CALLS APPROPRIATE INTERNAL FUNCTION. 
TESTS ERROR BYTE BEFORE RETURN 
REGISTERS CHANGED: 
NONE 



DISPAT: 



10$: 



MOV 


RO.-{SP) 


MOV 


Rl.-(SP) 


MOV 


R2.-(SP) 


MOV 


R3.-CSP) 


MOV 


R4.-(SP) 


MOV 


PC.Rl 


SUB 


#..R1 


MOV 


0TABLE-2.RO 


ADO 


Rl.RO 


TST 


(RO* 


TST 


(RO) 


BMI 


llOJ 


CMP 


(R0)*.XC0(R5) 


BNE 


10* 


ADD 


{R0).R1 


JSR 


PC.(Rl) 


BR 


240» 



; HERE IF ILLEGAL FUNCTION 
110* 



240 (: 



» ABORT 
MOVB 

MOV 

MOV 

MOV 

MOV 

MOV 

TSTB 

RTS 



OILLERR 
#-l.XER{R5) 

(SP)».R4 
{SP)*,R3 
(SP)*,Ri 
{SP)«.R1 
(SP)..RO 
XER(R5) 
PC 



{SAVE 



TRUE ADDRESS 

DIFFERENCE 6ETUEEN TRUE L 
APPARENT 

DO A TABLE SEARCH 
GET REAL ADDRESS 
TO NEXT FUNCTION 
END OF TABLE ? 
MI - YES 

IS IT OUR FUNCTION ? 
NE > NO 

ELSE GET REAL ADDRESS 
AND DO IT 
AND LEAVE 



jNOT LEGAL COMMAND 
: SIGNAL 



J RESTORE 



{FUNCTION TABLE 

TABLE: .WORD 
.UORD 
.UORD 
.UORD 
.WORD 



;Set error indicator 
FIRST ELEMENT IS FUNCTION. SECOND IS ROUTINE 



INIT$.INIT 
RES$FN.RESTOR 
READ ». DRIVER 
WRITE $. DRIVER 
-1 



INITIALIZE 
MONITOR RESTORE 
BLOCK READ 
BLOCK URITE 
END OF TABLE 



N2 
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.SBTTI. MAIN ROUTINE: INIT 

; * ************* 

: ROUTINE TO INITIALIZE THE DEVICE 
i INPUTS: 

NONE 
I OUTPUTS: 
i ROUTINES CALLED: 
i REGISTERS CHANGED: NONE 



INIT: CLRB XER(R5) 
RTS PC 



: ASSUME GOOD RESULT 



B3 

.PAGE 

.SBTTL MAIN ROUTINE: RESTORE 

: ROUTINE TO READ PART OF THE MONITOR CORE IMAGE 
I CALL AS FOLLOUS: 

; PUT BLOCK NUMBER RELATIVE TO MONITOR IN XDT(R5) 

: PUT NUMBER OF UOROS TO READ IN XUC(R5) 

i PUT ADDRESS TO READ INTO IN XBA(R5) 

i PUT REUS»FN IN XC0(R5) 

: JSR PC.a)IS(R5) 

! GOOD RETURN: DATA READ 

I ERROR RETURN: DIS TESTS XER(R5) BEFORE RETURN 
I ROUTINES CALLED: DIS(R5} 
1 REGISTERS CHANGED: NONE 



RES'^OR: ADD M0NBLK.XDT(R5) 

MOV •READI.XCOCRS) 

JSR PC.aOIS(R5) 

RTS PC 



MAKE BLK NUMBER RELATIVE TO 0 
DO A READ FUNCTION 
LET DRIVER DO IT 



C3 



.PAGE 

.SBTTL MAIN ROUTINE: DRIVER 



READ-URITE DRIVER FOR THE RJP04 

CALLED FROM DISPATCH 

PERFORMS READ$ AND URITEt FUNCTIONS 

6000 RETURN: 

TRANSFER EFFECTED. XER(R5) CLEARED 
ERROR RETURN: 

MESSAGE TYPED. XER(R5) NONZERO 

REGISTERS CHANGED: 

R0.R1.R2.R3.R4 



DRIVER: 





^1 on 

CLRB 






MOV 


•11 . .R* 


wPDR* 1 : 


DEC 


DA 






t 

33» 




MOV 






nov 


vnu^DO on 




Die 






nuV 


Oft Dorc^ro'^^ 




MAM 

MOV 


» 1 Ov vv , HKUH K 3 J 




Mm/ 
MOV 






Mm/ 

now 






Ncu 






MAW 

nov 






nov 


ynT f DC ^ 01 




Mm/ 

nuv 


«ec. .He 




CLH 


RO 


* * : 




R2 Rl 




BLO 


2$ 




INC 


RO 




BR 


1> 


2J: 


ADD 


R2.R1 


MOV 


Rl.-(SP) 




CLR 


Rl 




MOV 


ei9..R2 


3»: 


SUB 


R2.R0 




BLO 


4$ 




INC 


Rl 




BR 


3» 


4i: 


ADD 


fl2.R0 




SUAB 


RO 




BIS 


CSP)«.RO 




MOV 


H0.RPDA(R3) 




MOV 


R1,RPDC(R3) 




CMP 


«READ«.XC0(R5) 




BNE 


10» 




MOV 


»PJREAD.(R3) 




BP 


30$ 

•RjUPIT.(R3i 


1C$: 


MC; 



ASSUME SUCCESSFUL RESULT 

# OF TIMES TO RETRY ON ERRORS 

SHOULD WE CONTINUE? 

NO. SO REPORT ERROR 

DEVICE ADR 

GET UNIT NUMBER 

STRIP OFF ANY JUNK 

LOAD RESULT INTO RPCS2 

SET 16 BIT FORMAT IN RFQF REG 

DO A f-ACK ACK TO SET VV BIT 

UORD COUNT 

TWO'S COMPLEMENT OF UC 

BUS ADR 

BLOC NlMER 

22 SECTORS PER TRACK 

DIVIDE BY SECTOR SIZE 

UP TRACK COUNT 

UENT TOO FAR 

PUT SECTOR • ON STACK 

sl9 TRACKS PER CYLINDER 
DIVIDE BY TRACKS PER CYL 
TO GET TRACK AND CYL » 
UP CYL COWT IN Rl 
RO IS HOLDING TRACK 0 
MAKE UP FOR GOING TOO FAR 
MOVE TRACK 0 TO LEFT 
OR IN RIGHT SIDE (SECTOR) 
TO DSK ADR REG 
TO DSK CYL ADR REG 
IS A READ ? 

NE » NO. MUST BE A WRITE 
ELSE START IT 

START WRITE 



D3 



7 c 




AnniUClCDDnD /DT^ 

wUUNt !tKKUK , I H3 J 


iUuNb UK cKHOK? 






3U» 


. kJCTTLJCD 

i Nti 1 ntK 




DDI 








OTT 


wivOyOO.HrtHll HJ J 


;U«5 M DATA CHtCK FRROR? 




DC U 


JC ♦ 


itU * NU 




DTT 


A inn OOCOIfOT^ 










. uc * kin 






r'L • CLLLUH 


.Cl cc ^nooc^T TT 
;tLc>t LUHHtLT 11 




MOV 


#40.RPCS2(R?) 


: CLEAR ERROR CONDITION 




TSTB 


(R3) 


;UAIT TILL DONE 






11 1 

31 * 






RO 




;ANU LcAVt 


sc* z 


MOU 
nuv 




ionVC CNNUN INrUKnMllUrl 








.fftkiTOfti 1 ro Cl rAo 




1 9 I D 








ROl 










OAftftftft Oft 


.UAC TT uAon roofto? 




RFQ 




.Mft 


XXt . 

J j» : 














• TuinTrATc roDfto 

■ iliUlLnIt tKNUK 








■ WHO CKKUK UN HtML/; 




tstu 




. VCC 

: Tea 




.FRCTYP 


AMUTFRR 


•PPTNT URTTF FRROR 




6R 


201 


;RETURN TO CALLER 


36S: 


.FRCTYP 


•nRDERR 


{PRINT READ ERROR 


20): 


RTS 


PC 





E3 
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.SBTTL ROUTINE ECCCOR 



CORRECT A SOFT ECC ERROR 

(ALGORITHM ADAPTED FROM THAT IN CZR6PD) 

USES HARDWARE ERROR BURST PATTERN TO CORRECT A FAULTY 

SEQUENCE OF UP TO U BITS 



CALLED BY DRIVER 

GOOD RETURN: 

DATA CORRECTED IN BUFFER 

REGISTERS CHANGED: 
R0.R1.R4 



ECCCOR: MOV 
CLR 
MOV 
MOV 
MOV 
MOV 
ASL 
MOV 
ADO 
DEC 
MOV 
ASR 
ASR 
ASR 
BIC 
CMP 
BHIS 
ADO 
BIC 
BEQ 



1%: 



5$: 



ASL 
ROL 
DEC 
BNE 

MOV 
MOV 
BIC 
BIC 
BIS 
CMP 
BEQ 
MOV 
MOV 
BIC 
BIC 
BIS 

TST 
MOV 
PTS 



RPEC2(R3).ECCPAT 

ECCPAT.2 

R3.-(SP) 

RPEC1(R3).R1 

XBA(R5).R3 

XUC(R5).R4 

R4 

R3.-(SP) 

R4.(SP) 

Rl 

Rl.RO 
Rl 
Rl 
Rl 

«1.R1 
R1.R4 
10$ 
R1.R3 

#177760. RO 
5% 

ECCPAT 

ECCPAT,2 

RO 

3$ 

(R3).R0 

ECCPAT. Rl 

ECCPAT. (R3) 

RO.Rl 

R1.(R3). 

{SP).R3 

10$ 

(R3).R0 
ECCPAT. 2. Rl 
ECCPAT.2. (R3) 
RO.Rl 
R1,(R3) 

(SP). 

(SP)..R3 

PC 



ERROR BURST PATTERN 
UILL SHIFT INTO THIS 
SAVE 

ERROR BURST POS COUNT 
BUFFER ADDRESS 
UORO COUNT 
NOW BYTE COUNT 
CALCULATE END OF 
TRANSFER 

CONVERT TO BIT DISPLACEMENT 
SAVE 

COMPUTE BYTE DISPLACEMENT 



UORO DISPLACEMENT 

ERROR UITHIN TRANSFER? 

HIS « NO. RETURN 

COMPUTE BUFFER ADDRESS OF ERR 

STARTING BIT DISPLAC IN UORO 

EQ ' ON WORD BOUNDARY 

SHIFT PATTERN 1 BIT LEFT 
POOR MAN'S ASHC 
DECREMENT COUNT 
UNTIL DONE 

CORRECT FIRST WORD 
UITH XOR OF PATTERN 
POOR MAN'S XOR 



.•CHECK IF SECOND WORD IS 
;IN BUFFER. EQ« NO. ALL DONE 
iELSE 00 NEXT UORO 



J BUMP TEMP STORAGE 



F3 



SEQ 0031 



SECONDARY BOOT CODE AREA 
BCOOE: 



PAGE 

SBTTL BOOTSTRAP REVISION HISTORY 



REV DATE 



1.0 
1.1 
1.2 
1.3 



12-JUL-78 
17-N0V-78 
12 JUL -82 
29-MAR.83 



21-FEB-84 



CHANGE 



INITIAL ISSUE 

MAKE COMPATABLE WITH XXOP* 
MODIFIED TO SUIT VAX ASSEMBLER 
UHEN TRYING TO BOOT TO UNIT OTHER 

THAN 0 AND UNIT 0 NOT ON BUSS. 

HALT AT 216 OCCURS 
V2 CHANGE STACK AND MON SIZE 



G3 



.PAGE 
.SBT7L 



RBBOOT : 



RBCSA: 
START: 



5»: 
10$: 

15$: 



20$: 
25$: 

»0$; 



BOOTSTRAP 

.NLIST CNO 
.LIST MEB 



RBCSl 

R6UC 

R6BA 

RBDA 

RBCS2 

R60S 

RBOC 

BEGIN 

MONCNT 

NOP 
BR 

.WORD 

HALT 

.WORD 

HALT 

.BLKB 



- 0 

' 2 

' 4 

' 6 

• 10 

' 12 

« 34 

» 1046 

' 20000-256. 



START 
6 



12 



.WORD 176700 



SEQ 0032 



;SI<1P BOOT BLOCK 



; START BOOT ROUTINE 

; TRAP CATCHER 

{RESERVED INSTRUCTION ERR 

s TRAP CATCHER 



;RJP04 DEFAULT CSR ADDRESS 



NOP 

BR ST ART 1 

.BLKB 12 

.UORD 0.0 

.BLKB 24 

MOV »60000.SP 

MOV RBCSA. R5 

MOV #23. (R5) 

MOV RBCS2(R5).R2 

BIC *177770.R2 

MOV e40.RBCS2(R5) 

MOV R2.RBCS2(R5) 

BIT #100200. (R5) 

BEQ 10$ 

BMI 25$ 

TSTB RBDS(R5) 

BPL 15$ 

MOV #-M0NCNT.RBUC(R5) 

MOV #1000,RBBA(R5) 

MOV #5OO3«l.RB0A(R5) 

MOV #0.RBDC(R5) 

MOV #71. (R5) 

BIT #100200. (RS) 

BEQ 20$ 

BP.. 30$ 

MOtf (R5J.R0 

MOV RBCS2(R5),R1 

HALT 

BR 5$ 

MOV R5.R1 

JMP a#BE6IN 



SET UP STACK 

GET RBCSl ADDRESS 

00 PACK ACK TO SET VV BIT 

GET UNIT NUMBER 

CLEAR CONTROLLER 
SET UNIT NUMBER 
READY? 
NO 

ERROR 

DRIVE READY? 
NO 

SET UP UORD COUNT 
LOAD AT LOCATION 1000 
BLOCK # OF MONITOR 
CYL « 

DO READ COMMAND 
DONE OR ERROR? 
NOT DONE 
DONE 

SAVE STATUS 
AND ANY ERRORS 
HALT ON ERROR 

OK, TRY AGAIN . ^ 

PUT CSR ADDRESS IN DRIVER TABLE 
START UP HIMON 



.END 



H3 

SEG 

Appendix: 0 Assembly and Linking Instructions 



The Or ver and Boot must be merged together and then 
assmbled as a .MAC file. They should be maintained 
separetly as shown in appendix A, that is they have 
their OMn revision blocks. Assembling them together 
helps to eliminate double references that would otherwise 
occur. References to an absolute location by the BOOT code 
must be done via an offset from BCOOE:, which will be at 
absolute zero dur'ng the boot operation. 



Command f'le for DB under VMS 



i Command file to create a XXOP V2 06 DRIVER 

i 

i MCR MAC DB.DB/CRF/-SP=MACROM.MAC.OB.MAC 
I 

! Set the address limits for the driver and create 

! a binary file 

• 

i MCR TKB 

0B/NOMM/N0H0/SQ.DB/-SP-DB 
/ 

PAR«OUMMY: 0:3200 
STACK«0 

/ 

$ URITE SYSiOUTPUT " Now type TKBBIN <CR> , " 

$ URITE SYSJOUTPUT " Uhen prompted for the file name enter DB." 

$ URITE SYStOUTPUT " will create a driver called OB. BIN ." 
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SEQ 0034 

Appendix: C - Driver Equates 



XXDP* Version 2 



Equate Definitions 



DEVICE COnrlANO CODES 



INIT* 


= 


0 


READI 


X 


1 


WRITE* 


= 


2 


RES$FN 


r 


3 


RFS»FN 




100 


RFDiFN 




101 


PRE*TP 




200 


REUJTP 




201 


SPR$TP 


a 


202 


UHD$TP 




203 


RHDJTP 


s 


204 


SEF$TP 




206 


UEF*TP 




207 


SET$TP 




210 


STA$TP 




211 


DEN$FN 


s 


374 


CMP*FN 




375 


URTJFN 




376 


RED$FN 




377 



INITIALIZE DEVICE and BRING ON LINE 

READ 

WRITE 

RESTORE FUNCTION for XXDP-SM 

REFORMAT SINGLE DENSITY 

REFORMAT DOUBLE DENSITY 

TAPE - PREPARE 

TAPE - REWIND 

TAPE - REVERSE SPACE 

TAPE - WRITE HEADER 

TAPE - READ HEADER 

TAPE - SKIP to EOF 

TAPE - WRITE EOF 

TAPE - SKIP to EOT 

TAPE - RET'JRN STATUS CODE 

RETURN DENSITY (0 » LOW, 1 « HIGH) 

COHPUT BLOCK # from SECTOR 

WRITE absolute SECTOR 

READ absolute SECTOR 



DEVICE CODE BYTE 



BBSUP* 
NOREN$ 
NOOIR« 
TAPED* 
REFDN$ 
MULUN* 



= 2 
= 4 

10 
- 20 
= 40 
= 100 



BAD BLOCK SUPPORT 
TAPE CANNOT RENAME FILE 
NOT A DIRECTORY DEVICE 
IS A TAPE DEVICE 

SUPPORTS SINGLE/DOUBLE DENSITY FORMAT 
DRIVER SUPPORTS MULTIPLE UNITS/DRIVER 



DEVICE RETURNED STATUS BYTE 



BOTTP$ - 2 
TMKTP$ = 4 
EOTTP$ = 10 



TAPE IS AT BOT 

TAPE IS AT TAPE MARK 

TAPE IS AT EOT 



J3 



Appendix: 0 - Device Type Codes 



The Device Type Code (DTC) is placed nto byte locat'on 41 by tne 

Tn i s byte i s then 
DTC's are assigned as 



(Bonitor every ti 
designated the " 

follOMS: 



I me a binary ♦tie is run. 
load medium indicator". 



DTC 


DEVICE Type 


XXDP« 


Vers i on 


0 
1 


paper tape or ACT 11 
TU56 (DECtape) 


1.3 
1.3 




2 


RK05 (disk) 


1.3 




3 


RP02/RP03 (disk) 


1.3 




4 


TniO (magtape) 


1.3 




5 


TAll (cassette) 


1.3 




6 


TU16/Tn02 (magtape) 


1.3 


2.0 


7 


not used 






10 


RXOl (floppy disk) 
RP04/R50S/RP06 (disk) 


1.3 




11 


1.3 


2.0 


12 


RS03/RS04 (disk) 


1.3 




13 


RK06/RK07 (disk) 


1.3 


2.0 


1* 


RLOl/02 (disk) 


1.3 


2.0 


15 


RX02 (disk) 


1.3 


2.0 


16 


HM02/RM03 (disk) 


1.3 


2.0 


17 


TU58 (cassette) 


1.3 


2.0 


20 


TU58/PDT11 (cassette) 


1.3 




21 


TS04 (tape) 


1.3 


2.0 


22 


TM78 (tape) 


1.3 


2.0 


23 


UDA (disk MSCP) 


1.3 


24 


TR79 (tape) 


1.3 




25 


RD/RX50 (disk) 


1.3 


2.0 


26 


RC2S (disk) 


1.3 


2.0 


27 


TK50 (tape MSCP TMSCP) 


1.3 


2.0 



Notes 



NOTES: 



1. These are MSCP class devices and under XXDP V2 are 
handled by one driver which uses DTC ■ 23 



